為什麼要分層次思考

企業導入 Agent 可觀測性時，常見的誤區是「先裝一套監控工具再說」，卻沒有先想清楚要監控的到底是哪個層次的問題。這篇提出一個三層次框架，幫助團隊在動手之前先釐清範圍。

第一層：基礎設施層

這是傳統 APM 就能處理的範圍：運算資源的 CPU/記憶體使用率、網路延遲、服務可用性。如果 Agent 跑在 Cloud Run 或 GKE 上，這層的監控方式跟一般應用沒有本質差異，用 Cloud Monitoring 的標準 Metrics 就能覆蓋。

第二層：模型呼叫層

這層開始跟傳統應用不一樣：每一次 LLM API 呼叫的延遲、Token 用量、成本、模型回傳的 finish reason（正常結束、被截斷、觸發安全過濾）。OpenTelemetry GenAI 語意慣例定義的 gen_ai.* 屬性（例如 gen_ai.request.model、gen_ai.usage.input_tokens）就是為了標準化這一層的資料——不管你呼叫的是 Gemini、還是透過其他管道呼叫其他模型，都能用同一套屬性名稱描述。

第三層：決策邏輯層

這是最難、也最容易被忽略的一層：Agent 為什麼在這個節點選擇這樣做。這層的資料不是單純從 API 呼叫就能自動取得，需要應用層主動設計——例如在 Planner 產生決策時，額外記錄一段簡短的推理摘要，或是記錄「考慮過哪些選項、為什麼選了這一個」。這正是 Day2 提到的「從動作到決策」在實作層面的落地，也是 Week 2 結構化日誌設計要解決的核心問題。

三層次的投資優先順序

多數團隊會自然而然先把第一層做好（因為工具現成、跟過去經驗一致），第二層次之（有 OpenTelemetry 標準可以參考），第三層往往被忽略，因為沒有現成模板，需要團隊自己設計。但真正決定「你能不能回答為什麼」的，恰恰是第三層——這也是這系列 Week 2 會花最多篇幅處理的部分。

這篇的檢查清單

• [ ] 目前的監控是否只停留在第一層基礎設施，還沒觸及模型呼叫與決策邏輯？
• [ ] 是否已規劃如何在應用層記錄決策理由，而不是只依賴框架自動產生的資料？